Possession of an identity is an important element to online communications; it is the
        basis for any online relationships which the user may have.  Identity provides
        relationship continuity, from one online session to the next.  Because of the value that
        users usually place on their identities, this is an area frequently targeted for
        exploitation; among other things, on Yahoo!, your identity is also likely to be your
        email address.  Anyone who has spent any amount of time in the Yahoo! "Hackers'
        Lounge" will be aware of how popular the subject of gaining illicit access to someone
        else's email, is.  

        Yahoo! identifies it's users, in virtually all of it's services, using Netscape cookies.  (It
        is known as a Netscape cookie, because cookies are an extension of the HTTP -
        commonly referred to as the web - protocol, created by Netscape, to allow web
        servers to maintain stateful information, such as identity, across the otherwise stateless
        HTTP protocol.)  Yahoo! provides the user with a new cookie, each time that the
        user authenticates, and this cookie is used often, in any communication with Yahoo!
        involving the user's identity.  

        To obtain a cookie, for an identity, a user must connect to a web server designated
        for authentication, such as edit.yahoo.com, and submit a GET query to a CGI script,
        containing the authentication information.  It is interesting that this is typically done
        in-the-clear, meaning that the transaction is not encrypted; the password an username
        are clearly labeled and visible, in the request header,  A sample request header is
        shown below:  

        GET /config/ncclogin?.src=bl&login=mryowler&passwd=testing&n=1 HTTP/1.0  
        Host: edit.yahoo.com  

        If you are accessing the web through a proxy, you must connect to the proxy server
        (on the web proxy port; usually something like 8080, or 1080), and submit a similar
        GET query, with one important difference; a GET query that passes through a proxy
        must use an absolute web address, as opposed to the relative web address, shown
        above.  An example of a proxied request header is shown, below:  

        GET
        http://edit.yahoo.com/config/ncclogin?.src=bl&login=mryowler&passwd=testing&n=1
        HTTP/1.0  
        Host: edit.yahoo.com  
          
          

        As you can see, the username is "mryowler", and the password is "testing" (not the
        real password for this account!), in this example.  

        After transmitting this to the authenticating web server on the HTTP protocol, a
        response is returned, containing a great deal of useful information.  There will always
        be an HTTP response header, and it will contain a couple of  Set-Cookie elements,
        but these elements are only useful if the authentication succeeds.  Here is an example
        of a result from an authentication attempt that failed:  

        HTTP/1.0 200 OK  
        Date: Sun, 09 Jul 2000 11:41:28 GMT  
        Cache-Control: private  
        Pragma: no-cache  
        Expires: Thu, 05 Jan 1995 22:00:00 GMT  
        Connection: close  
        Content-Type: text/html  
        Set-Cookie: B=1qercdcsmgp78&b=2; expires=Thu, 15 Apr 2010 20:00:00 GMT;
        path=/; domain=.yahoo.com  
        Set-Cookie: Y=%2e; expires=Thu, 15 Apr 2010 20:00:00 GMT; path=/;
        domain=.yahoo.com  

        ERROR: Invalid NCC Login  
          
          

        Here is an example of one that succeeded (the cookies have been line-wrapped to fit
        within reasonable space:  

        HTTP/1.0 200 OK  
        Date: Sun, 09 Jul 2000 11:50:27 GMT  
        Cache-Control: private  
        Pragma: no-cache  
        Expires: Thu, 05 Jan 1995 22:00:00 GMT  
        Connection: close  
        Content-Type: text/html  
        Set-Cookie: Y=v=1&n=579b6sm8lrkmu&l=choemb4h/o&  
        p=m2300004130002&r=45&lg=us&  
        intl=us; expires=Thu, 15 Apr 2010 20:00:00 GMT; path=/; domain=.yahoo.com  
        Set-Cookie: T=z=EcGa5AEcGa5AQAFilv12FjHMzIGMDE1MU9PNDYx&  
        a=AAE&sk=DAAujluyoWQ1YE&  
        d=c2wBTkRVQk56WXlOamc0TXpFMgFhAUFBRQF6egFFY0dhNUFBQUE-;
        expires=Thu, 15 Apr 2010 20:00:00 GMT; path=/; domain=.yahoo.com  

        OK  
        BEGIN BUDDYLIST  

        END BUDDYLIST  
        BEGIN IGNORELIST  

        END IGNORELIST  
        BEGIN IDENTITIES  
        MrYowler  
        END IDENTITIES  
        Mail=0  
        Login=MrYowler  
          
          

        Exploiting it: 

        As you can see, there is a great deal of information, in the authentication request and
        response.  

        Brute-Force Cracking: 

        Traditional Yahoo! brute-force password crackers often attempt to try a large list of
        relatively common passwords, on a given username.  The way that this works, is that
        the cracker sends a large number of these requests, to one or more authentication
        web servers, and waits for an affirmative response, like the one shown above. 
        Relatively recently, Yahoo! implemented security measures on the authentication
        servers, to prevent these types of attacks from succeeding, by limiting the number of
        authentication requests that would be accepted, within a particular period of time. 
        This has, to a large extent, put an end to brute-force password cracking on Yahoo!
        online identities, using traditional tools.  

        Man-in-the-Middle: 

        Because the authentication requests send the username and password, in-the-clear,
        they are subject to man-in-the-middle attacks.  Anyone who has access to a system in
        between a Yahoo! user and the authentication server, can collect that user's username
        and password, from that system.  Common places from which such an attack can
        occur, include any router or proxy server, along the path between the user and the
        Yahoo! authentication server, or any host (a web server, or the like), that is not
        segmented from these routers/proxies, by a switch or similar segmenting network
        traffic device.  This sort of attack would be capable of collecting information only
        about the Yahoo! users on the network segment that the man-in-the-middle is sitting
        on, and is therefore generally effective against random usernames, only - unless the
        attacker is able to position the man-in-the-middle, between his intended victim, and
        the Yahoo! authentication server.  To do so would require that the attacker have
        some idea where, on the Internet, the victim is connecting from.  (This can generally
        be determined from the victim's IP address, from the current or a recent session; most
        people consistently connect to the Internet, from the same place/s, and through the
        same network/s.)  

        Another possible attack, involves DNS-spoofing the Yahoo! authentication servers,
        on the users' DNS servers; thereby redirecting authentication requests to a false
        authentication server controlled by the attacker.  An attack of this type could
        conceivably capture the usernames and passwords of all the users that use the
        targeted DNS servers, and relay the authentication information to the proper Yahoo!
        authentication servers.  The Yahoo! authentication servers would then send the
        necessary cookie data back to the false authentication server, which could then relay
        it back to the user.  This would result in the username and password being captured
        by the attacker's false authentication server, without notifying the victim.  This type of
        attack would require that the attacker have access to an Internic-registered domain
        name server (for the DNS-spoofing attack), a false authentication server, and
        knowledge of which nameservers the victim uses.  (This can generally be determined
        by examining the victim's IP address, as outlined above, and using that information to
        determine what Internet access provider the victim connects to the Internet through. 
        Once the attacker has this information, either the Internet provider's web page, or
        technical support service should indicate what domain name servers the victim is
        using; failing that, it should be possible to make an educated guess based upon
        information obtained by either examining the Internet provider's domain registration
        records, with the Internic, or by examining the results of a domain name query, on the
        Internet provider's domain.) 

        The Stupidity of the Victim: 

        Perhaps the single most common attack (short of the 'brute-force' attack, which has
        been largely eliminated), is the attack which relies upon the stupidity of the victim. 

        Enough people seem to have enough of a burning desire to invade someone else's
        privacy, that when offered a way to do so, they will gladly give up their own privacy,
        in exchange.  This type of attack is a form of social engineering, that exploits this
        tendency, by offering the victim exactly what they want; whether it is a way to read
        someone else's email, a way to cheat at some online game, a way to make money, or
        some other temptation.  The victim is offered whatever they want, if only they will
        send an email (or ICQ message, or whatever) to some address (presumably an
        official-looking one, that might be able to provide whatever they are looking for),
        containing their own username and password, whether encoded in some way (usually
        embedded in a web address), or not. 

        Now, the (official-looking) email address (or ICQ number, or whatever) actually
        belongs to the attacker, who now has everything needed to assume control of the
        victim's online identity.  Generally speaking, the victim will never get anything remotely
        resembling what they wanted. 

        There are a nearly infinite variety of permutations to this type of attack.  One example
        is that the attacker can send the victim a trojan server, and tell the victim that it is a
        program which will give them whatever they want (perhaps it's a 'hacking' program or
        maybe it's a program to disable banner ads on the free Internet access services or the
        pay-to-surf services - or maybe it's a program to make the victim's Internet
        connection run faster, for example).  The trojan server is then used to gain control of
        the victim's computer, and passwords/usernames (along with credit card numbers,
        and any other identifiable sensitive information) gets extracted.  Another example is
        one in which the victim is asked to go to a web site, and enter the username and
        password, in order to get whatever the victim wants.  A variation on this theme, is the
        'false login page', wherein the victim is presented with a web page that looks like the
        Yahoo login page, but is in fact, a web page belonging to the attacker.  These can be
        detected, by examining the web address of the page, and noting that it is different
        from the Yahoo login page.  The possibilities, for attacks that rely upon the victim, to
        do something stupid, go on and on. 

        This type of attack is unreliable, because you cannot always count on the stupidity of
        the victim - sometimes they will, in fact, turn out to be too stupid even to follow the
        instructions they are given, by their attacker.  And, although an amazingly large
        segment of the human population can indeed be astoundingly stupid (see "nuclear
        weapons; Cold War", for an explanation), the problem is not, as some would have
        you believe, universal.  Not everyone can be relied upon to behave as ideal victims,
        and do as their attacker instructs - worse, the ones that know better, might just know
        how to perpetrate the more technically complex, but also more reliable attacks, and
        may choose to reciprocate against the attacker!